Comments/Ratings for a Single Item
I don't have Zillions, and I do not have the slightest interest in buying it, as it plays like cr*p.
Perhaps you are unaware that Andreas Kaufmann wrote a Winboard Adapter for Zillions of Games.
Rich, I think it is putting the cart before the horse to try to define software interoperability standards before there is any software using them. Software standards need to arise out of actual software, as Standard C arose from the original Unix C, or as ECMAScript arose from the original JavaScript. Software standards for integrating Game Courier with a GUI or a game engine would have to arise from an actual project of trying to integrate Game Courier with some actual piece of software, and I would have to work with the programmer on this, not with someone who is just spinning ideas and not doing any programming. Furthermore, my greater interest right now is in helping a GUI gain more of the capability of Game Courier, especially in graphics and in the capacity to handle more types of variants. Zillions of Games has a great interface, but it is too weak for many games, especially Shogi-like games. My special interest is in having a strong Shogi program that can use the graphics I have designed for Shogi and which can handle some of my Shogi variants, such as Kamikaze Mortal Shogi and the Hex Shogi games.
Hello Fergus. I want to comment here: 1. There ARE programs out there that can benefit from this, and websites. On the programming front, there is Axiom (and Zillions), ChessV, Cyberboard, and Winboard. 2. You are touching on a chicken and egg issue if you were to go with 'there is no software out there'. Well, unless there is standardized protocols, you aren't likely to see programs created specifically for that. And unless the programs are out there, then sites go they aren't going to bother. All this then becomes an excuse for not doing anything. 3. As for AIs being poor, well not sure what that has to do with providing a GUI for people to be able to play over a server against other people. What I will say is, if you develop the communication protocols to enable interoperability, using what is out there now (see names above), then you will provide a place for people to work on AIs that are stronger. They could even work with Axiom to be able to code up stronger AIs. So, things are out there now. What is needed is to get them to work, and not have people make excuses to justify the way things are today. Also, if you do want to work with a developer on this, please contact me at: rich [at] iagoworldtour.com or richardhutnik [at] optonline [dot] net. The developer of Axiom (Greg Schmidt) is working with Aaron Dalton of the SDG site to get Axiom to interface with his site. It is in discussions now. It would be helpful to email me, and I can get you the link to the forum, and also their email addresses, so this can come about. So, in a nutshell, there are things afoot now, and getting Game Courier to also tie in and work would helpful.
>>I don't have Zillions, and I do not have the slightest interest >> in buying it, as it plays like cr*p. Whoever said that isn't aware that there are tweaked Zillions chess variants programs that play a fine game of chess. The problem is, namely, that Zillions tends to move about with knights too much in the opening, and develops the queen too early. It also sometimes misjudges the value of the pieces. It moves the king to the corner too readily. But all this can be easily corrected by tweaking. I always do this in my implementations: http://tinyurl/chessvariants One example is my implementation of Chinese Chess. It plays much better than the standard implementation while the latter greatly overestimates the value of the cannon compared with the rook, and underestimates the Elephants and the Mandarins. It values them according to mobility, so they get a too low value. But in Chinese Chess their blocking capability, king protective capability, and their functionality as screen for the cannon, give them a higher value. So one must tweak them to give them a higher value, otherwise Zillions can't simply play correctly. That's why I asked Larry to tweak the pieces in his Xiang Hex. /Mats
Fergus: | How does that work? Does WinBoard allow the use of graphic images for | pieces? Game Courier allows the use of GIF images for pieces. Does it | allow any customization of the board's appearance? Game Courier allows | GIF, PNG, and JPG images for boards, and it can draw multiple kinds of | boards. If WinBoard can use images for boards and pieces, then I would | be happy to contribute some. WinBoard can use arbitrary bitmap files for the square coloring (through options /liteBackTextureFile=... and /darkBackTextureFile=... on the command-line or in the winbord.ini file. For some examples, see: http://usuarios.lycos.es/alexwbtm/Test/ or http://www.open-aurec.com/wbforum/viewtopic.php?t=49439 (bottom). The pieces cn be user-defined through the option /renderPiecesWithFont=... and /fontPieceToCharTable='...', which can be used to select any pictorial true-type font for piece rendering, and define the mapping of pieces to font symbols. A good example of this would be the Superchess font obtainable from http://www.superchess.nl.
Fergus: | Software standards for integrating Game Courier with a GUI or | a game engine would have to arise from an actual project of trying to | integrate Game Courier with some actual piece of software, and I would | have to work with the programmer on this, ... Well, so WinBoard is the GUI, and I am your man! :-) | Furthermore, my greater interest right now is in helping a GUI gain | moreof the capability of Game Courier, especially in graphics and in | the capacity to handle more types of variants. It has always been my aim to develop WinBoard in this direction, and I think I already made a very good start at this. | Zillions of Games has a great interface, but it is too weak for many | games, especially Shogi-like games. Agreed. The level of Zillions is probaby perfect for beginners, but it is no match for dedicated engines. And especially piece drops are a weak spot in its search algorithm. | My special interest is in having a strong Shogi program that can use | the graphics I have designed for Shogi and which can handle some of my | Shogi variants, such as Kamikaze Mortal Shogi and the Hex Shogi games. Building a Sogi engine is one of the things on my to-do list. I decided to re-write my Chess engine Joker (and have actualy started working on that) in such a way that it is more friendly to implementation of variants, e.g. using a 10x10 board as basis (so that 8x8, 10x8, 9x9 and 9x10 can be implemented as a subset, by filling a larger part of the internal 16x16 board with edge guards, besides the 3-wide guard band). Adding piece drops to that would be a very good basis for a strong Shogi engine.
M. Winther: | Whoever said that isn't aware that there are tweaked Zillions chess | variants programs that play a fine game of chess. Well, as I have no Zillions, I cannot test that. What (computer) rating do you think Zillions would have in (properly tweaked) normal Chess? Could it beat Fairy-Max / micro-Max? I doubt that very much, and Fairy-max is only a very mediocre engine, (what can you expect from a mere hundred lines of code?), about 500 Elo weaker than a good engine, and about 1000 Elo below the World top (=Rybka). From the unspeakable World Championship, where Fairy-Max beat Zillions, I got the impression that Zillions is tactically weak. It just doesn't search deep enough.
WinBoard can use arbitrary bitmap files for the square coloring
I once considered letting Game Courier use image tiles for making boards, but I eventually decided to just let it use a single image for the whole board. This is simpler to do, and it looks more natural than repeating the same pattern on multiple squares, especially when using marble and wood grains. Can Winboard specify an arbitrary image for each space, such that something like Smess or Storm the Ivory Tower would be possible?
The pieces cn be user-defined through the option /renderPiecesWithFont=... and /fontPieceToCharTable='...', which can be used to select any pictorial true-type font for piece rendering, and define the mapping of pieces to font symbols.
Using fonts is better than nothing, but it creates a stumbling block to developing images for use with Winboard. Although many piece sets are available, we don't have anyone ready to translate them into fonts, which leaves Winboard unable to use them. Also, I imagine that the fonts are normally greyscale line drawings, not full color images. This would prevent Winboard from using some of the nicer pieces I've designed.
I think WinBoard uses the bitmap for the entire board, or tiles it if the bitmap you have given is not big enough to cover the entire board. I did not code this part myself, so I cannot give you the details off hand. There are additional options /darkTextureMode and /liteTextureMode that control if some additional randomization is done in the process of cutting the squares out of the given bitmap. I am not sure how this works exactly, I hardly ever use the texture modes, as I like evenly colored squares better. Fonts are better than bitmaps, because the bitmaps cannot be scaled. So for every board size you would have to remake the bitmaps from scratch. The font can be rendered at any size. Fonts are indeed pure black/white constructs. The black defines the outline, and any internal areas are filled with another color to get a shading effect. The colors and shading are user-selectable. I am not so sure about the desirability of having multi-colored pieces (on top of outline and two colors for defining the filler shading gradient). It seems to me that this would only degrade the ease of recognizing which side the pieces belong to.
Muller, it's not always relevant to test a program against other programs. Most chess programs beat 99% of humans. Nevertheless, they are smashed by Rybka, and completely annihilated. Of course, Zillions loses against stronger programs. But is it fun and developing to play against it? Yes, it is. Zillions, on a modern computer, plays chess at, perhaps, Elo 2150-2200. It plays an entertaining game, too, advancing boldly with the pawns on the wing, etc. I always tweak it to make pawn moves in the opening, and discourage early queen excursion. Then it plays a rather mature game. I am a good judge, because I'm a quite strong club player. Moreover, Zillions understands all those strange new pieces better than humans do. So it often wins by utilizing them better. It takes longer time for a human to develop a grasp of a cannon or a catapult, etc. Zillions is clearly the best way of testing chess variants, whether they are fun, whether they are interesting strategically, etc. Zillions is a remarkable tool for chess variants. People in the chess community are often interested in which program has the highest rating, but who cares? Zillions is actually the best chess program because it plays most variants. /Mats
Gentlemen, let me jump in here. I've been following the discussions on standards with great interest and a greater lack of knowledge. But when I see something 'dangerous' to design, I will say something. Here, I'm very concerned about the idea of not using color for the pieces. I've already done a basic game design that requires multiple colors per side, have 2 games already using the pieces, and am working with another designer to create a range of games that use these and similar pieces. Honestly, I have been intending to add more and differently-colored pieces to the Alfaerie:Many piece set. Heh, if this site stays up, I hope to post some game pages over the next few days that will include large multi-move games, some with multi-square pieces defined by color, like Chesimals I. I appreciate programmers need cut-off points. But designers need freedom. [I have actually discovered the hard way that game courier 'only' accepts about 48 moves for one player in one turn.] The flexibility of Game Courier is a beautiful thing. Please don't take any of that flexibility away in the future. Expand it if possible.
'Zillions, on a modern computer, plays chess at, perhaps, Elo 2150-2200.' That might be true against Humans in 5-min games, but I have strong doubts that that has any bearing on how strong it is. Based on Zillions performance in Gothic Chess I estimate its rating more round 1800 Elo. When I had micro-Max play on the ICC server against Humans it also quickly converged on a rating of 2260, but it seems that almost any computer program, no matter how poorly it plays, does that. I once saw a report of Tord Romstad, about his attempts to reduce the playing strength of his engine Glaurung. At some point he had crippled it so much that it would litterally score 0% against TSCP (an extremely weak engine, which micro-Max would totally crush), and blundered away a piece or rook nearly every other move. It still kept beating 2100-rated players on ICC! Anyway, Zillions might suit your needs, it definitely does not suit mine. I need computer opponents to test my engines, so it is not really relevant how many variants Zillions plays, just that it plays the variants for which I have built engines. And if even the most basic engine I build totally crushes it, I can learn nothing from playing it against Zillions. My reason for playing engines against each other is to test which one of different versions is better. If all versions score close to 100%, I can learn nothing from it. And if I would want to play a variant against a computer myself, I might as well configure Fairy-Max to play that variant. Of course even if Zillions were strong enough, it would still be useless to me, as it cannot play automatically against other engines at all...
| Fergus: || Software standards for integrating Game Courier with a GUI or || a game engine would have to arise from an actual project of trying to || integrate Game Courier with some actual piece of software, and I would || have to work with the programmer on this, ... | Well, so WinBoard is the GUI, and I am your man! :-)
I would like to start with integrating Game Courier with a game engine. I have some ideas for how this can be done. First, Game Courier has its own programming language, GAME Code, and all calls to game engines would be done through lines of GAME Code. It would be coded into an individual preset whether it uses an external game engine.
The first thing a game engine would be used for is to check the legality of a move. When a player moves, a line of GAME Code would send the moves and any other information the engine needs to the external engine. Since this is done within the context of a GAME Code program written for a specific game, it would be easy to customize the information it gives to the engine, depending upon what the engine needs. An engine for one game only might just require the moves, while a more customizable engine might require more data. At the bare minimum, the engine would indicate whether all the moves passed to it are legal. With this confirmation from the engine, the GAME Code program could move the pieces around on the Game Courier board without checking the legality of the moves any further. Hopefully, the engine could give some detailed error messages when a move is illegal, such as mentioning the specific illegal move and explaining why it is illegal. If not, Game Courier could call the engine multiple times with longer sequences of moves, so that it can itself identify the specific illegal move. It's also possible that the engine could return FEN code, and some lines of GAME Code would just update the board to match the new FEN without actually performing the moves the player gave. This would allow the use of game specific notation that even Game Courier cannot understand.
The second thing a game engine would be used for is to play a game. As long as the engine moves fast enough, it could feed its moves directly to Game Courier when it gets called by the GAME Code. If its going to take longer, PHP might have a problem with the time it takes to get a response and stop execution before it returns a move. If so, another means will be needed to tell when the engine has moved, perhaps by using JavaScript.
Fonts are better than bitmaps, because the bitmaps cannot be scaled.
Game Courier uses bitmaps and rescales them for JPG, PNG, and GIF boards.
I am not so sure about the desirability of having multi-colored pieces (on top of outline and two colors for defining the filler shading gradient). It seems to me that this would only degrade the ease of recognizing which side the pieces belong to.
I will answer this with a picture:
This picture was created by Game Courier from multi-color pieces, and it was also rescaled. The use of multiple colors allows the pieces to look more realistic. Basically, allowing multi-color images allows photographic quality pieces.
Since Shogi pieces are all the same color, here is another image from Game Courier, this time of Xiang Qi, whose pieces are different colors.
Muller, which are the chess variants you are testing? Zillions is World Champion in several hundred chess variants. Rybka is only World Champion in one. Without Zillions, how would it be possible to test and try Hexagonal Chinese Chess, recently invented by L. Smith? It would take a century. And it beats me easily in Xiang Hex when I try it. Zillions is very appropriate for 99% of all chessplayers. It's beyond me how a person interested in boardgames can refrain from buying Zillions at $20. /Mats
M. Winther: | Muller, which are the chess variants you are testing? Zillions is World | Champion in several hundred chess variants. That does not really prove much about its strength if it was the only contender... I have been testing games like Shatranj, Knightmate, Capablanca, Superchess (as in Superchess & Monarch), Falcon Chess, Great Shatranj. And I am testing many 'unofficial' variants consisting of one or two unorthodox pieces embedded in a conventional setup, e.g. replacing Knights with Cannons, Modern Elephants or Dababbas, or (pairs of) Grasshoppers, Ferzes, Wazirs, Xiangqi Horses; Rooks with Nightriders, Queens with Centaurs or Amazons. Usually in setups with different Armies, on 8x8 or 10x8 boards. | Rybka is only World Champion in one. Without Zillions, how would it be | possible to test and try Hexagonal Chinese Chess, recently invented by | L. Smith? It would take a century. Well, the game does not seem listed here, so it is hard for me to comment on it. If I would be interested in it, I might configure Fairy-Max to play it. If very exotic pieces that defy Fairy-Max' piece-definition format would participate, and I was interested enough, I would hard-code the particular piece in Fairy-Max, or add general support for the property that made it impossible before. (I did this for the Falcon, for example.) In general I am not so much interested in entire variants, as in individual Chess pieces occurring in those variants. | And it beats me easily in Xiang Hex when I try it. Zillions is | very appropriate for 99% of all chessplayers. It's beyond me how | a person interested in boardgames can refrain from buying Zillions | at $20. This is because I am not interested in playing against engines, but in building them, and I already have developed engines that can do the things I am interested in (piece value measurements) which I consider highly superior to Zillions (w.r.t. playing strength). If I had teleport ability, why would I buy a Rolls Royce?
To Fergus: It seems that you have an application / need for the extra colors because you are not just displaying the piece symbols, but are actualy trying to create a realistic image of the game as it would be played with physical pieces. Personally I don't think this is very desirable; I would prefer to play Shogi without th pentagonal outlines and Xiangqi without the circles. The Linux version of Winboard, xboard, does have the possibility to have user-defined graphics called 'pixmaps', and I am not sure there is any limitation on the number of colors that can be used in them. (They have the undesirable property, however, that they represent square and piece together.) What software do you use to scale the GIF files? I always get excessively ugly reslults when I do that. Even when my browser scales a gif image of a Chess poition, separation lines between board squares are randomly disappearing, etc.
Muller, in Zillions there is, among the standard games, a variant called Fairy Chess. By right-clicking you can insert fairy pieces (e.g. grasshopper) in a standard piece context, on an 8x8, or a 10x10 board. So it's easy to create unequal armies this way. I have invented many interesting pieces of the catapult type, bifurcation, cannon variants, etc. You could always try to implement any of these pieces if you like them: http://hem.passagen.se/melki9/chessvar.htm There is also an implementation of diverse Capablanca variants there. Piece evaluation in Zillions can be corrected by a tweaking method which I always use. The result is very good, but it's hard to tell if it's perfect. The method has drastic positive results. I tested my implementations of Chinese Chess and Korean Chess against the standard Zillions versions. Almost the only difference was that I had tweaked the pieces so that their value was corrected. The result was that my versions won 6-0 in both matches. So it is possible to compensate for Zillions deficiencies in piece evaluation. Remember that it is still a programmin tool, and you can do much advanced programming. I bet you wouldn't be able to program certain of my most advanced pieces in Fairy-Max. /Mats
Thanks you everyone for discussing this. My interest in this is not in the minutia, or how everyone will get there, just that we get there. In this, my main interests is that everything everyone is working on, will be able to work with one another (of course, I have a bias towards things being easy to do, but complete, so that whatever is decided upon will get used and adopted). And, as we expand to cover more areas, everything together is able to handle it. From an IAGO perspective, the system would not only be able to handle chess variants, but also stacking games (as seen Focus, and a chess variant I saw where pieces were made up of a stack of pieces), and games with piles or areas, like the Mancala family. If we get interoperability right here, then you could have a case where the CV site and its members could play against people on the Scheming Mind site, for example. This is my concern here, and I hope whatever is reached is used. I am sure there are many paths to get to where one needs, the idea is to make sure the paths work together. In regards to Zillions, Zillions was an example of one program that could work. Something else could be used instead. However, if one uses open standards, someone may encode a plug in for Zillions to be able it to also work. The open standards approach would enable GC to be integrated with by a LOT of engines, if the makes of engines and client programs know what the specs are to code to. We can get one to work (say Axiom) and then others see it can. They would then make their programs work also, and the CV site could get more people involved and greater traffic. Just my 2 cents. And thanks again for the input.
M. Winther: | I bet you wouldn't be able to program certain of my most advanced | pieces in Fairy-Max. As Fairy-Max is written in C, and C is a recurive language, and recursive languages are equivalent to a Turing machine, and a Turing machine can calculate anything that is calculable, you would lose that bet with mathematical certainty! Moves of Catapult pieces, for instance, are akin to castling moves, and it would be fairly easy to built something into Fairy-Max that would allow this type of 'castling'. If I had the motivtion to do it. The Catapult pieces do not particularly appeal to me, as they violate what I consider to be one of the defining characteristics of a Chess variant: that it moves only one piece per turn. Note that am not in any way denying that what I do, could be done by Zillions. But the differences I want to measure do not result in 6-0 scores. A Pawn advantage in Chess results only in 18% advantage, and even less in Capablanca-type variants. I want to measure piece values to a precicion of at least a quarter Pawn, resulting in advantages of ~3%. To get the statistical noise below that I need 50-1000 games, so I cannot afford to let the engines spend half an hour on a game. They must play 1-min games, and play them at a sufficient high quality for the results to be meaningful. So I want the best engine I can get, and I doubt Zillions would qualify as such. But you can convince me by showing that Zillions can beat Fairy-Max in, say, Knightmate.
It seems that you have an application / need for the extra colors because you are not just displaying the piece symbols, but are actualy trying to create a realistic image of the game as it would be played with physical pieces.
Personally I don't think this is very desirable; I would prefer to play Shogi without th pentagonal outlines and Xiangqi without the circles.
We each have our preferences. In general, your program will appeal to a broader base when it can accommodate more preferences than just your own. For example, Game Courier uses some graphics I don't like and supports many games I have never become interested in, but it is more popular than it would otherwise be because I didn't limit it to my own preferences.
What software do you use to scale the GIF files? I always get excessively ugly reslults when I do that. Even when my browser scales a gif image of a Chess poition, separation lines between board squares are randomly disappearing, etc.
I use the GD library that comes with PHP. What I do is create a whole board image, then rescale that. I don't rescale individual pieces. The advantage to doing it this way is that I get in-context anti-aliasing of every piece with the space it occupies.
Fergus: | We each have our preferences. In general, your program will appeal to | a broader base when it can accommodate more preferences than just your | own. For example, Game Courier uses some graphics I don't like and | supports many games I have never become interested in, but it is more | popular than it would otherwise be because I didn't limit it to my own | preferences. Before I invest in that, I would want to be sure that there are actually people that want to use this feature at all. The user base of WinBoard seems to be far more interested in the games they use it for, and how well and reliably it supports the rules of those, than in having multi-colored pieces. They don't use WinBoard for generating artwork to hang on their walls... The way you scale the entire board, if I could find similar function in the Windows graphics library, does sound like it might be very expensive. Doesn't anti-aliasing involve Fourier transforming the image back and forth? You would have to do that every time the board changes (i.e. every move). Anything CPU-intensive is a no-no in a GUI that run on the same machine as the engines. There are already people that are complaining WinBoard currently uses more CPU time than they can afford fo their purpose (wich is playing sub-second games). Although there i a general truth in the things you say, I still think it is good to keep well-defined priorities. There is still so much that can be done. I think the risk that there are people that say: 'I am not going to play Shogi, as the pieces have only a single color' is very small. They are either interested to play Shogi, and would do no matter what to achieve that, or they don't. In fact there is a lot that can be done with just outline and inner color. The Xiangqi pieces you show are in fact just that. The outline and the (solid) piece symbol are one color, the inner regions another. The WinBoard system could easily handle that. You could have designed the Shogi pieces similarly.
Wouldn't it be possible to be able to have a way for diverse systems to chat and then everyone picks their own way they want to render the interface for players? Just curious...
Before I invest in that, I would want to be sure that there are actually people that want to use this feature at all.
There's me for one. I don't use Winboard, because it has poor graphics, and I don't think it yet supports any games I'm interested in well-enough that I can't play with another program that has better graphics. For now, I prefer to use ChessV, which plays many games well and includes some of my own graphics with it. I have a good Shogi program that came in a commercial suite that also includes Chess and Xiangqi, though I prefer other programs for those games, such as Chessmaster and Coffee Chinese Chess.
The user base of WinBoard seems to be far more interested in the games they use it for, and how well and reliably it supports the rules of those, than in having multi-colored pieces.
Yes, probably because the poor graphics turn off those who care about such things. My point is that you can expand your user base by allowing easier customization options for graphics.
They don't use WinBoard for generating artwork to hang on their walls...
I don't use Game Courier or Zillions of Games for that purpose either, but I do like to use a nice looking board and piece set when I play a game.
The way you scale the entire board, if I could find similar function in the Windows graphics library, does sound like it might be very expensive. Doesn't anti-aliasing involve Fourier transforming the image back and forth? You would have to do that every time the board changes (i.e. every move). Anything CPU-intensive is a no-no in a GUI that run on the same machine as the engines. There are already people that are complaining WinBoard currently uses more CPU time than they can afford fo their purpose (wich is playing sub-second games).
I'm no expert on how anti-aliasing is done. I just use a function supplied by the GD library. But I can tell you it is done very fast, and I expect Winboard would have to do only between moves, not when it needs all the CPU power for calculating a move. Anyway, resizing boards is not as important as just allowing bitmap images to be used for boards and pieces. It makes a difference only for large variants that don't easily fit on the screen. Game Courier's boards and pieces are at a scale that normally fits the screen for most games and usually don't need to be resized.
I think the risk that there are people that say: 'I am not going to play Shogi, as the pieces have only a single color' is very small. They are either interested to play Shogi, and would do no matter what to achieve that, or they don't.
I'll still play Shogi, but if Winboard plays Shogi only with shoddy graphics, I will play Shogi with another program. The issue here is not whether people are sufficiently interested in Shogi but whether your program would be a more appealing option than some other program.
In fact there is a lot that can be done with just outline and inner color. The Xiangqi pieces you show are in fact just that. The outline and the (solid) piece symbol are one color, the inner regions another. The WinBoard system could easily handle that. You could have designed the Shogi pieces similarly.
Shogi is a good reason for including multi-color pieces. In Shogi, the promoted sides of pieces are normally red rather than black. This makes it easier to tell promoted pieces from unpromoted ones, and it is crucial when you are using a westernized set in which the promoted pieces use the same images as the unpromoted pieces.
To Rich: Indeed, I think it is good to have diversity. There is no point whatsoever in giving WinBoard and GC all the same capabilities, as one of them would then be superfluous. The requirements for a GUI are entirely different from the requirements for a game-play server. GC wil never make a useful GUI for engine-engine play, and WinBoard will never make as versatile a client to a server that can prepare html pages as a browser. In the areas where the tasks they can perform overlap, it only enriches the world that they are different. People can then choose what they like best. I would very much like to have an easier way of scaling the size of the display, but if it is computationally too expensive, the efficiency requirement hould take clear priority. I am a firm believer in the 'maximum flexibility, minimum usefulness' principle. Therefore I refrain from trying to make WinBoard do everything. If there are tasks that have too little in common with what there is now, it would be of no benefit to cram those into WinBoard. I would, for instance, never teach it the rules of Checkers, Othello or Go to make it possible to use it as a GUI for those games. There is too little synergy to make that pay off.
| There's me for one. The keyword in this phrase is 'one'... :-) | I don't use Winboard, because it has poor graphics, and I don't think | it yet supports any games I'm interested in well-enough that I can't | play with another program that has better graphics. Well, if that is your opinion then I am happy you do not use it. If there are other programs with graphics that you like better, then I could only win you over by providing similar graphics. That would be a total waste of time, as I would be making something that apparently exists already. I have absolutely nothing to gain by competing with other programs in their own niches through mimicry. WinBoard is not a commercial program, and I therefore don't care how small it user base is. What I care about is that it provides opportunities to its users that they cannot find anywhere else. | For now, I prefer to use ChessV, which plays many games well and | includes some of my own graphics with it. I have no experience with ChessV, as it does not support automated play against other engines. In the Unspeakable World Championhip 2007 it ended well below Fairy-Max, but Gregory told me that this was an obsolete version used without his permission, not representative of the strength of current versions. | I have a good Shogi program that came in a commercial suite that also | includes Chess and Xiangqi, though I prefer other programs for those | games, such as Chessmaster and Coffee Chinese Chess. Well, nice for you. Just play the Kamikze Mortal Shogi with that one, then. But it is of no use to me, as the Shogi program is no doubt not capable of automated play against, say, TJshogi or GNUshogi, or to the Shogi engine I will be developing. | Yes, probably because the poor graphics turn off those who care about | such things. My point is that you can expand your user base by allowing | easier customization options for graphics. Well, I have never heard any complaint about this before, and current users are eager enough to complain about many other aspects they don't like, so it doesn't seem to be true in general that perceived shortcomings immediately deter them from using it. | I'm no expert on how anti-aliasing is done. I just use a function | supplied by the GD library. But I can tell you it is done very fast, Very fast is a relative notion. Something that needs to be done 60 times in a 1-min game doe not have to be visibly slow before it starts to soak up a sizable fraction (say 5%) of the CPU time. Correspondance Chess has other standards. | and I expect Winboard would have to do only between moves, not when it | needs all the CPU power for calculating a move. The problem is that in engine-engine games you always need all CPU power for calculating move, as when it i not engine A's turn to move, engine B should start thinking. Plus that these programs often want to think in the opponent's time as well. | Anyway, resizing boards is not as important as just allowing bitmap | images to be used for boards and pieces. It makes a difference only | for large variants that don't easily fit on the screen. Well, it doe to me, and many like me: a I have a dual-core PC I play two games simultaneously, and would like to fit both WinBoard displays next to each other, together with the control windows of the corresponding two tournament managers. And soon I will have a quad (or, when I get my way, even an octal core or dual quad)... | Game Courier's boards and pieces are at a scale that normally fits | the screen for most games and usually don't need to be resized. Yes, if you only want to have one game on screen, and not four. | I'll still play Shogi, but if Winboard plays Shogi only with shoddy | graphics, I will play Shogi with another program. The issue here is | not whether people are sufficiently interested in Shogi but whether | your program would be a more appealing option than some other program. Well, to some it is. To me it is. That is enough for me. | Shogi is a good reason for including multi-color pieces. In Shogi, | the promoted sides of pieces are normally red rather than black. | This makes it easier to tell promoted pieces from unpromoted ones, | and it is crucial when you are using a westernized set in which the | promoted pieces use the same images as the unpromoted pieces. Well, there is no red in the Japanese set I have, that's for sure. Using the same image for the promoted and unpromoted piece is just bad design of the piece set. By the same token you could represent all Chess pieces by Pawns, and then complain how essential it is to have their heas rendered in all different colors to distinguish a Knight from a Queen... The built-in winBoard representation does not suffer from this. Promoted pieces are clearly distinct from the unpromoted versions there. They look like the piece they promote to, while stil betraying their origin.
|| There's me for one. | The keyword in this phrase is 'one'... :-)
I can only speak for myself, but I doubt I'm alone.
| If there are other programs with graphics that you like better, then I | could only win you over by providing similar graphics.
No, that doesn't follow. You could win me over by providing better graphics. Besides, all I want is the ability for me to provide you with better graphics. I am not asking you to provide any additional graphics. I have the graphics. I want the ability to use them with Winboard.
| That would be a total waste of time, as I would be making something that | apparently exists already.
No, it would not be a waste of time at all. The only programs with the kind of graphics capability I want are Zillions of Games and a couple Chinese Chess programs with customizable graphics. Everything else comes up short, even ChessV, because it doesn't use images for boards.
|| I have a good Shogi program that came in a commercial suite that also || includes Chess and Xiangqi, though I prefer other programs for those || games, such as Chessmaster and Coffee Chinese Chess. | Well, nice for you. Just play the Kamikze Mortal Shogi with that one, | then.
That is not an option. It is a commercial program that only plays Shogi and does not include any graphics for the Kamikaze piece.
|| Anyway, resizing boards is not as important as just allowing bitmap || images to be used for boards and pieces. It makes a difference only || for large variants that don't easily fit on the screen. | Well, it doe to me, and many like me: a I have a dual-core PC I play two | games simultaneously, and would like to fit both WinBoard displays next | to each other, together with the control windows of the corresponding two | tournament managers. And soon I will have a quad (or, when I get my way, | even an octal core or dual quad)...
Since Winboard already supports fonts, you do have the option of using fonts instead of rescaled bitmaps. Adding a new feature to your program does not force you to use it. And if you added the feature, you could avoid the need to rescale altogether by creating some smaller bitmap pieces.
| Using the same image for the promoted and unpromoted piece is just bad | design of the piece set.
That depends on the set. I would not use the same images for a Japanese set, and my Symbolic set uses different images, but the set I based on the Chess Motif font uses standard Chess piece images, and it makes sense for this set to just change the color for the promoted pieces.
| By the same token you could represent all Chess pieces by | Pawns, and then complain how essential it is to have their heas rendered | in all different colors to distinguish a Knight from a Queen...
No, what works well in moderation does not always work well when taken to an extreme.
| The built-in winBoard representation does not suffer from this. Promoted | pieces are clearly distinct from the unpromoted versions there. They look | like the piece they promote to, while stil betraying their origin.
I would not know if this is true, because Winboard would not let me make a single move when I tried to use it for Shogi.
|| I would like to start with integrating Game Courier with a game engine. | If I understand you correctly, you would want this engine to run on the | same computer that acts as server for GC.
If it could. Otherwise, it might be enough to call an engine on another server. But I do want to look into the possibility of running an engine on the server. I know this website runs on a FreeBSD server. Would Fairy-Max run on a FreeBSD server?
Right now, I need to know what the most basic steps would be. I need to know where to put the engine, what protocol to use to communicate with it, and how I could do this through PHP.
Muller, to get piece values at ~3% exactitude you would need to presuppose that piece values are static properties. But they are really changeable with regard to tactical and strategical context. This means that you would probably have to foresee the future in, say, ten moves in order to get a ~3% exactitude. One obvious example is XiangQi. Chinese Chess masters are hard pressed to reveal the relative values of pieces. Those pieces which are completely lousy, like the elephant and the mandarin, are sometimes very valuable while they provide protection for the general, function as screens for the cannon, or can block enemy pieces. So, in a certain context they become very valuable. Ten moves later, the elephant or mandarin is useless. Probably, in chinese chess, only a human is capable of evaluating a piece. /Mats
M. Winther | Muller, to get piece values at ~3% exactitude you would need to | presuppose that piece values are static properties. But they are | really changeable with regard to tactical and strategical context. Not necessarily. I always measure piece values in a well-defined context, e.g. opening values, end-game values. Piece values are by definition strategic quantities, I avoid starting in tactical positions, and for an accurate measurement I average over many non-tactical initial positions with similar peiece makeup. This usually gives quite consistent results, when you keep the number of pieces and the total value of present material approximately constant. (i.e. the difference of the performance of two diffent pieces is hardly dependend on the details of the makeup of the opponent or its allies.) That piece values change as the board empties, because. e.g., Rooks get more freedom of movement and Cannons can find fewer platforms, is something that can be measured separately. If the piece values found for the various qualitatively different situations differ, you can try to add material-interaction terms in the evaluation. (The best known example of such a term in normal chess is one proportional to the product of the number of Bishops and number of Pawns, making the effective B-N difference dependent on the number of Pawns.) | This means that you would probably have to foresee the future in, | say, ten moves in order to get a ~3% exactitude. I am not sure what you mean by 'forsee the future'. By playing out the game until checkmate or legal draw, I effectively make a Monte-Carlo sampilng of all plausible futures. But it is important that the sample is generated under conditions of reasonabe tactical accuracy, or you would not be sampling a representative set of realistic positions, which then would distort the results. | One obvious example is XiangQi. Chinese Chess masters are hard pressed | to reveal the relative values of pieces. Those pieces which are | completely lousy, like the elephant and the mandarin, are sometimes | very valuable while they provide protection for the general, function | as screens for the cannon, or can block enemy pieces. So, in a certain | context they become very valuable. I have not built an engine to play Xiangqi yet (I am in the preliminary design stage now of an engine that could play Shogi, Chess and Xiangi with arbitrary Chess men on boards upto 10x10.) So I have not done any measurements for tuning. Quite possibly the material-interaction terms in Xiangqi are much larger than in Chess, due to the peculiar capture mode of the Cannon and the restricted access pieces have to the board. It seems to me that the effects you describe can be described reaconably well by cross-product terms of number of Cannons and number of other pieces. This transcends pure piece values, but can be measured just as easily. | Ten moves later, the elephant or mandarin is useless. Probably, in | chinese chess, only a human is capable of evaluating a piece. Such a fast change is usually tactical, and then has little to do with strategic piece values. Unles the strategic situation completely changed in those ten moves, e.g. because all heavy material got traded, or all hoppers got traded. But in that case such differences can easily be expressed by terms that are proportional to the amount of heavy material / number of hoppers. I doubt if Humans could do this job better than computers. This is why I would like to build a Xiangqi engine, so that I could do similar tests on piece values as I am doing now for Chess.
| If it could. Otherwise, it might be enough to call an engine on | another server. But I do want to look into the possibility of | running an engine on the server. I know this website runs on a | FreeBSD server. Would Fairy-Max run on a FreeBSD server? Fairy-Max is available in source (this is included in the WinBoard_F download), and the source can be compiled both for Windows and Linux. You have to define the macro LINUX to make it use a Unix-like call for reading the clock. I suppose this would also work on FreeBSD. | Right now, I need to know what the most basic steps would be. I need | to know where to put the engine, what protocol to use to communicate | with it, and how I could do this through PHP. WinBoard engines are normal console programs that communicate in plain text. So it is fairly easy to run them on another machine, using a remote shell there to which GC connects.
| No, that doesn't follow. You could win me over by providing better | graphics. Besides, all I want is the ability for me to provide you | with better graphics. I am not asking you to provide any additional | graphics. I have the graphics. I want the ability to use them with | Winboard. It would be very nice to add other graphics to WinBoard, but I want to avoid unlimited bloating, so I think te requirements should stay within reason. In particular I want to avoid providing a zillion different mechanisms for doing exactly the same thing, especially if each of them would only work in different situations. (E.g. colors working only with bitmaps, and scaling working only with fonts.) | No, it would not be a waste of time at all. The only programs with | the kind of graphics capability I want are Zillions of Games and a | couple Chinese Chess programs with customizable graphics. Everything | else comes up short, even ChessV, because it doesn't use images for | boards. Well, non of the graphics code in WinBoard is of my own hand, but I have taken a peek at it. At the WinBoard part at least. This code is platform dependent, and the Linux version, xboard, has completely different code for this. WinBoard has built-in bitmaps (2-color for black pieces, 3-color for white, one of the colors being 'transparent') for each size, and scalable tri-color font-based pieces which are customizable. Xboard has 2-color built-in 'bitmaps' (transparent + color; no outline), and 4-color 'pixmaps' (including the square in the 4th color, so that a duplicate set is needed), both non-scalable, but both customizable. I consider it a very undesirable that WinBoard and xboard are so different here, but phasing out customizability options in which sers might have heavily invested is something that is 'not done'. My prevference would be to switch to a single, platform-independent graphics package and format for internal use (built-ins), and convert the obsolete customization input formats to this internal format. In WinBoard things basically lready work that way, MicroSoft monochrome bitmaps being the internal format (using 2 layers to create the white pieces), and font-based rendering converting the given font to such bitmaps. In the WinBoard graphcs code, there seems noting that resticts it to monochrome bitmaps; the number of colors is part of the bitmap definition in MicroSoft format. I am not sure if the MicroSoft graphics library supports transparent color. Currently this is emlated by anding and orring bitmaps together, wchich in black and white has a well-defined effect, but with multiple bits per pixel might not always do what you want. If a solution can be found for this, there would be nothing against using many-color bitmaps as internal format. Such bitmaps would then also be suitable as customization input (like xboard already does for monochrome bitmaps), PROVIDED an acceptable way for scaling the user input to the current disply size can be found. Of course people having very special desires that are to uncommon to make it likely to be supported can always customize their own private version of WinBoard by changing the built-in bitmaps, and recompiling it. WinBoard is open source. | That is not an option. It is a commercial program that only plays Shogi | and does not include any graphics for the Kamikaze piece. That is what I mean. If WinBoard were the only program that remotely supports what you want to do, you would use it despite the perceived minor shortcomings. | Since Winboard already supports fonts, you do have the option of | using fonts instead of rescaled bitmaps. Adding a new feature to | your program does not force you to use it. And if you added the | feature, you could avoid the need to rescale altogether by creating | some smaller bitmap pieces. Like I explained above, I don't want to add too many features aimed at doing the same task. | That depends on the set. I would not use the same images for a | Japanese set, and my Symbolic set uses different images, but the | set I based on the Chess Motif font uses standard Chess piece images, | and it makes sense for this set to just change the color for the | promoted pieces. I don't understand this. Promoted pieces in Shogi move completely different from their unpromoted counterpart, so the symbol for a corresponding standard Chess piece would be completely different. I would think it made sense to represent pieces that move the same by the same symbol. | I would not know if this is true, because Winboard would not let | me make a single move when I tried to use it for Shogi. This is strange. Was that because you could not select Shogi at all, because you had no engine? If you click 'view or edit games' in the startup dialog, you should not need any engne, and it sould accept all moves. Be sure to use board size middling or bulky if you want to see al the pieces, though, as for Shogi, not all sizes have built-in bitmaps.
Muller, obviously you know the mathematics. But I question the relevance of determining piece value to the decimal. The method I have used is to see how well a piece fares in a Western piece context, e.g. how many moves does it make compared with the other pieces (i.e. how useful it is). Another method is when I pit the new piece(s) against a different army of known pieces. If the result is equal after a number of games, then I regard the piece as equally valuable as its counterpart in the other army. So this is a practical testing method of determining piece values, which I let Zillions do automatically. I have found that when a piece is valued, perhaps, 2.5, or 3.5, then it tends to converge around the piece value 3, e.g. the same as a bishop or knight. The point is, namely, that the new piece can threaten exchange, or vice versa. And the threatened party cannot withdraw for strategical or positional reasons. Hence the piece values converge around the nodes of 3 and 5. Remember that also the formally higher valued piece can often threaten exchange to achieve a positional or tactical goal. So, they are worth the same due to practical factors, while they are *practically* interchangeable*. Obviously, in an equal army variant both players can exchange the new piece, and the remaining position is still equal. Hence, the new piece is equally valuable as a light piece. To really introduce a different valued piece, then it must by pinpointed at 4, I suppose. I don't know if this phenomenon can be mathematically represented. It depends on the piece congestion, i.e. size of board, and whether the nearly equal valued pieces are long-shooting, i.e. whether they can easily be used to make an exchange. /Mats
M. Winther: | Another method is when I pit the new piece(s) against a different | army of known pieces. If the result is equal after a number of games, | then I regard the piece as equally valuable as its counterpart in the | other army. So this is a practical testing method of determining piece | values, which I let Zillions do automatically. This is essentially the same way I do it. (Except that I do not use Zillions, but Fairy-Max or Joker80.) Try to set up nearly equivalent piece combinations, by making as few substitutions as possible in the array defining the context. If a side wins modestly, I give it additional Pawns odds to swing the balance, and gauge the remaining difference compared to the Pawn value. | I have found that when a piece is valued, perhaps, 2.5, or 3.5, | then it tends to converge around the piece value 3, e.g. the same | as a bishop or knight. The point is, namely, that the new piece can | threaten exchange, or vice versa. And the threatened party cannot | withdraw for strategical or positional reasons. This effect is certainly present to a certain extent, but not as large as you make it out to be here. A difference of 5 centiPawn often occurs, and is very rea. Thi is well confirmed in normal Chess, where the value of the first Bishop to be captured is 50cP (the B-pair bonus) above that of any Knight. This can be based on GM games, and it is also what I find in computer self-play. On 10x8 a 50cP difference exists between B and N even in absense of other Bishops, and not telling the computer they were equal caused a neary 100 Eo drop in playing strength in results against other, unrelated engines. But it is true that for much smaller differences, like 20cP or less, a computer often performs better if you make it underestimate the difference. | Hence the piece values converge around the nodes of 3 and 5. Remember | that also the formally higher valued piece can often threaten exchange | to achieve a positional or tactical goal. The tendency to control willingness to sacrifice should not be tuned by the piece values, but by the value of the positional goal. | So, they are worth the same due to practical factors, while they are | *practically* interchangeable*. Obviously, in an equal army variant | both players can exchange the new piece, and the remaining position | is still equal. Hence, the new piece is equally valuable as a light | piece. I am not sure what you want to say with this. | To really introduce a different valued piece, then it must by | pinpointed at 4, I suppose. I think the B-N base-value difference in Capablanca variants clearly shows that this is not true. Ignoring a difference of 50cP really causes a large drop in strength. | I don't know if this phenomenon can be mathematically represented. | It depends on the piece congestion, i.e. size of board, and whether | the nearly equal valued pieces are long-shooting, i.e. whether they | can easily be used to make an exchange. All these effects are included in the empirical value determination by playing games. Fortunately self-play results are not very sensitive to wrong piece values (unlike playing wrong piece values against correct ones, wich makes you take a big hit). So if the values change in later game phases, so that values tuned to the starting position no longer strictly apply, the results are not significantly corrupted by this. So although it would be better to use an engine with very advanced evalution, taking material-interaction terms into account next to the piece values, this is not strictly needed for measuring the piece values. (But it would be essential for measring the more subtle interaction effects; if these are not recognized at all, they are simply randomly squadered, and an initial unrecognized advantages might not survive long enogh to affect the result. E.g if you play paired Bishops against unpaired Bishops (i.e. on the same color) with in engine that does not score the B-pair, the first Bishop is very likely to be traded so early, that the B-pair advantage does not get the time to affect the score.
Muller, it is interesting to note the 0.5 difference between bishop and knight in Capablanca's chess. An untweaked Zillions regards the difference as 0.523 in the beginning and as 0.446 in the middlegame. Both pieces increase their dynamic value, but the value of the knight increases more, having to do with the centralization of the knight. More than +0.5 is regarded as a clear advantage, but I cannot accept that the party who exchanges a knight for a bishop has almost achieved a clear advantage. In my own slightly tweaked version the difference is 0.499(!) in the beginning, but the difference is reduced in the middlegame, to 0.279. But a 0.3 points difference is significant enough. I have always though of this as a drawback to Capablanca's chess. That's why I invented the Donkey and the Kwagga, which are equally valuable as a bishop on the 8x10 board. /Mats
Does Zillions recognize and award the Bishop pair? Or do the values you give represent an average of the paired nd unpaired Bishop? Exchanging the first B (so you break the pair) against N+P turned out to be an equal trade in Capablanca. It seems strange that the difference goes down. Based on GM games in normal Chess, the B-N difference increases as more Pawns disappear (as one would expect towards the end-game), exact equality occurring if each side has 5 Pawns.
Hello Fergus. I am of the belief a major issue that would need to be worked out, is people determining what the protocols for communication will be and agreeing to use them. An approach I am seeing that could work, would be to break down each action distinctly. Selecting a position is one. Then selection which piece(s) in an position to move would be another. After this, where to move the piece(s) to follows. Then you resolve the results of the action of moving to (like a pawn promotion). Then you see if there is any other moves or a pass action. Between the interface and the play area is each discrete actions that are passed back and forth.
40 comments displayed
Permalink to the exact comments currently displayed.
How does that work? Does WinBoard allow the use of graphic images for pieces? Game Courier allows the use of GIF images for pieces. Does it allow any customization of the board's appearance? Game Courier allows GIF, PNG, and JPG images for boards, and it can draw multiple kinds of boards. If WinBoard can use images for boards and pieces, then I would be happy to contribute some.